UK Patent Application GB „„ 2 210 480„,A 

(43) Date of A publication 07.06.1989 



(21) 


Appiicatbn No 881901B.6 


(51) INTCL- 


G06F 12/12 


(22) 


Date of filing 10.08.1988 


(52) UK CL (Edition J) 


(30) 


Priority data 


G4A AMC 


(31) 104280 (32) 02.10.1987 (33) US 


(56) Documents cited 








US 0452138 B 


(71) 


Applicant 
Sun Microsystems Inc 


UK CL (Edition J) G4A AMC 




(Incorporated In the USA - Delaware) 


INTCL* G06F 




2550 Garcia Avenue, Mountain View, California 94043, 






United States of America 


(74) Agent and/or Address for Service 


(72) 


Inventors 


Potts Kerr and Co 


William Van Loo 


15 Hamilton Square, Birkenhead, Merseyslde, 




John Watklns 


L41 6BR, United Kingdom 




Robert Garner 






William Joy 






Joseph Moran 






William Shannon 






Ray Cheng 





(54) Flush support 

(57) Hardware and software improvements in workstations which utilize virtual addressing in multi-user operating systems 
with write back caches. Including operating systems which allow each user to have multiple active processes. The present 
invention supports data protection and the reassignment of virtual addresses within such a system. fJIulliple active 
processes have their own virtual address spaces, and an operating system is shared by those processes in a manner 
invisible to user programs. Cache "Flush" logic 33 is used to remove selected blocks from the virtual cache before virtual 
addresses are reassigned. A cache hit detector Is adapted to detect cache hits in the shared operating system across 
multiple active user contexts. 




At least one drawing originally filed was informal and the print reproduced here is taken from a later filed formal copy. 

This print takes account of replacement documents submitted after the date of filing to enable the application to comply with the format 

requirements of the Patents Rules 1982. 



1/23 



2210480 





2/23 

221048 

CPU Bus Address 

VA{15:4) — 
CX(2:C) — 
VA(27:17) — 
VA(16) — 

Cache Address 

VA(15:4) — 

Cache Tags 

CX(2:0) — 

VA(27:17) — 
VA(16) 

Valid * 
Supervisor Prot — — — — ^ 

FIG. 2a 




3/23 



Virtual Address Cache: 
Cache and MMU Prote ction Violations 



2210480 



CPU Bus Controls 

Write Bus Cycle 



User Access 
(Function Code = 0x2) 



Cache Tags 

Write Allowed 



Supervisor Access 
Required 



Cache Controls 

Cache Hit 




FIG. 2b 



48 



Cache 

Protection 

Violation 



CPU Bus Controls 

Write Bus Cycle 



User Access 
(Function Code « 0x2) 



MMU Page Map Bits 

Write Allowed 



Supen^lsor Access 
Required 



MMU Page Valid 



FIG. 2c 




MMU 

Protection 
violation 



4/23 



32 



Virtual Addr ess Write Back Cache: 

Address Path ^ ^ 



J- 



Context Reg 



CX(2:0) 



Cache Flush 
Logic ^ 

Match In 

AIn Din 



33 



VA(27:4) 



11 



CPU 



VA(27:0) 



MMU 



RA(27:13) 



27 



OX. VA(27:16) 



Cache Tags 



CX.VA(27:16) 



.23 



CPUVAOE 

\ 



VAR 

ex. VA(27:16) 



VA(15:13) 



CX.VA(27:16) 



Hit 
and 
Flush 
Match 



- Ctl 



X 

o 



Set 
VAR/VA 



\ VAR 

\ MUX VARATA / 

^ 1 \ ' 

I 45 



OX. 

VA{27:13) 



RA(27:13) 



51 

J. 



Real Adr Reg 



CtKRAR 



RAR(27; 



CX, VA(27:16) 



ToCPU Adr/0ataBu8 



FIG. 3 



5/23 



221C4eO 



Virtuol Addreas Coche: Address Stole Hochine 



MUX:SelCPUYA 
A^rt Cache Tag OE 



MUXrSel CPUYA 
Asdert Cache Tag OE 
Translate CPUYA 



State (•) 



State (c) 



Assert BusAcktoCPU 
Assert Bus Rctrg to CPU 
MUX:Se] CPU YA 
Assert Cache Tag OE 
ClkTagYAtoYAR 
Translate CPUYA 



State 




Gota Ce.n) 





MUX: Sel CPUYA 
Translate CPU YA 



State 



Assert BusAcktoCPU 
Assert Bus Error to CPU 
Set Prot Yiol bit in 
Bus Error Reg 
MUX: Sel CPUYA 
Assert Cache TagOE 
CI k Tag VA to YAR 
Translate CPUYA 



MUX: Sel CPU YA 
ClkCPUAdrinRAR 
Translate CPUYA 
Assert Mem Adr Strobe 
Assert Cache to Mem OE 



State («) 



State 
(c.v) 



Assert Bus Ack to CPU 
Ml«:Sel CPUYA 
Assert Cache Tag OE 
CI k Tag YA to YAR 
Translate CPU YA 



3: 




State 
(e.h) 



Assert Bus Ack to CPU 
Assert Bus Error to CPU 
Set ProtYiol bit in 
Bus Error Reg 
MUX: Sel CPU YA 
Translate CPUYA 
Oeassert Mem Adr Strobe 



State 

(i.v) 



FIG. 4a 



6/23 



Vlrtuin Alillr pss Tache: AUrtress State nachlne 



MUXrSelYAR 
Treiwlate Cwhc YA 
Assert CPU YAOE 
Assert Mem Adr Strobe 
Assert Ceche to Mem OE 



State (t.R) 



i 



MUXiSclYAR 
Translate Cache YA 
Assert CPU VAOE 



MUX:Sel VAR 
Translate Cache YA 
Assert CPU YAOE 
Update Cache Tags 
Assert Mem Adr Strobe 
Assert Cache to MemOE 



State (k) 



MUX:Sel YAR 
Translate Cache YA 
Assert CPU YA OE 
Assert Mem Adr Strobe 
Assert Cache to Mem OE 



State (n) 




MUX: Scl YAR 
Translate Cache YA 
Cite AdrtoRAR (at p) 
Assert CPU YAOE 
Dcasscrt Mem Adr Strobe 



State (t) 



MUXiSelYAR 
Translate Cache YA 
Assert CPU YAOE 
ClkYAtoYAR (ats) 



I 



MUX: Scl YAR 
Translate CPU YA 
Assert CPU YAOE 



State («} 



State (s> 



State (i) 




MUXrScl YAR 
Translate CPU YA 
Update MMU Statistic Bits 
Assert CPU YAOE 
Update Tag Yalid Bit 



State (v) 



^Gete(a) J 



FIG. 4b 



7/23 



2210480 



virtual Afloress cacne naia patn 



VA(15:3) 




CPU Write 
O.E. 



Cache Data 



. Data (127:64) 



Data (63:0) 



A(3)=0 
A(3)=1 



CPU Read O.E. 



(63:32) 



(31:0) 



Clk Data Reg — > Dola Reg (63:0) 



Clk 
WrlBk 



(31:0) 



\ 



Cache Data O.E. 



> 



Write Back Buffer 

D( 127:64) 



Write Back OE. 



0(63:0) 



(63:32) 



CPU Adr/Data Bus (63:0) 



To Real 
AdrReg 



/\7 /\7- Cache to 



Hem Bus AD( 63:0) 

(31:0) 



Mem O.E. 
Mem to Cache O.E. 
(63:32) 



Main 
Memory 



0027:64) 



D(63:0) 



A(3)=0 
A(3)=1 



FIG. 5 



22^0480 




[)ea33ert CPU Write OE 
Assert Bus Ack to CPU 
A»ert Bus Error to CPU 



State 
(c.w) 



1 



Write CPU Data into Cache 
Deassert CPU Write OE 
Assert'Bus Ackto CPU 



Deassert CPU Read OE 
Assert Bus Ack to CPU 
Assert Bus Error to CPU 



Sttte 
(e.wh) 



Read Cache Data to CPU 
Deassert CPU Read OE 
Assert Bus Ack to CPU 



State 
(•.rd) 



State 

(c.rd) 



Stete 

(e.rv) 



State 

(cm) 



FIG. 6a 



9/23 



2210480 



VirtusI Address Cache: Dots State Hachine 



0eas9ert CPU Write OE 
Assert BusAcktoCPU 
Assert Bus Rretry to CPU 



State 
(e.va) 



i 



Goto (e.rn) 



De835ert CPU Read 0£ 
As^rtBusAck to CPU 
Assert Bus Retry to CPU 



Assert Cache Deta OE 




Assert BusAck to CPU 
Assert Bus Error to CPU 
Assert Ceche Data OE 



Goto (t) 



State 
(e.rn) 



State (9) 



State 
(i.v) 



Assert Ceche Date OE 
Clk Write Back Bufer 
Invert Cache Adr b1tA(3) 



Assert Cache Data OE 



Assert Cache DataOE 
CI k Write Back Bufer 
Invert Cache Adr bftA(3} 



State 
(i.a> 



State (k) 



State (n) 




State 
(a.vt) 



State (a) 



FIG. 6b 



10/23 



Virtuol Addreaa Cochc: Doto Stole Mochine 
(Write Bus Cycle) 




ClkDdtaReg 
Merge CPU Data SKith 

Oate Reg: 
Assert CPU Write OE 
Assert Data Reg OE for 

Other Bytes 



Assert CPU Write OE 
Assert Data Reg OE for 
Other Bgtes 
Update Data Cache 
Invert Cache Adr bitA(3) 



Get* i% 



3 



Stete (q.v) 




State (s.v) 



G*to (a) 



FIG. 6c 



Ok Data Reg 
Deassert CPU Write OE 
Assert Data Reg OE for 
All Bytes 



Assert Data Reg OE for 
All Bytes 
Update Data Cache 



Assert hemorg Busy 
Assert Start Write 
Back Cycle 



State (q.v) 




State (v.v) 




State (g.v) 



11/23 



2210480 



VirtuQl Address Coche: Doto State Machine 
(Rea4 B09 C«c1e) 



Clk Oata Reg 
Assert CPU Read OE 
Assert Date Reg OE for 
All Bytes 



Assert CPU ReadOE 
Assert Date Reg OE for 
All Bytes 
Update Data Cache 
Invert CochcAdr b1tA(3) 



Slate (q.r) 




State (e.r) 



c 



Goto (a) 



FIG. 6d 



Clk Data Reg 
Deassert CPU ReadOE 
Assert Data Reg OE for 
All Bytes 



Assert Data Reg OE for 
All Bytes 
Update Date Cache 




Assert Memory Busy 
Assert Start Write 
Back Cycle 



State («.r> 




State (v.r) 



State (g.r) 



12/23 



Write Back Slate Machific 




Awert Memoru Busy 
Assert Memory Address Strobe 
Assert Cache to Memory O.E. 




Assert Memory Busy 
Desssert Memory Adr Strobe 
Assert Cache to Memory OE 



Assert Memory Busy 
Assert Memory Data Strobe 0 

(First 64 bit transfer) 
Assert Cache to Memory O.E. 




Assert Memory Busy 
Desssert Memory Data Strobe 0 
Assert Cache to Memory O.E. 



Assert Memory Busy 
Assert Memory Data Strobe 1 

(Second 64 bit transfer) 
Assert Cache to Memory O.E. 




FIG. 7 



13/23 



rarhe Write mss - Best Case Timing 



States 



nnu 



Cache Tag 

not 



VAMot. 



nuxsei 

VAR / VA 



Cache Hiss 
Read 



rmiuuuiFinjiruini 



TronlateCPU 
VlrtAddr. 



I I I I 



Tronslate Cache 
VJrtAddr. ' 



I I 

TranloteCPU 
iirlMtr. ■ 



L Cacshe J 

r~ TaoCE. ^ 



CPUVAO.E. 



Update 
Tags 



lUpdatel 
Tag 
Valid 



iCachei Clk 
Hit/ TagVA 
Miss? to VAR 



Clk RAl 
ItoRAR 



IcPuvJ 

|toVAR| 



Clk RA 
toRARl 



nUXSelCPUVA — ^U. 



hUXSelVAR 



k- CPU "H k— 

V^riteOE 



Cache Data O.E. 



Clk 




Clk 


Clk 


Update 


Clk 


WrtBk 




WrtBk 


Data 


Data 


Data 


Bfr; 




Bfr; 


Reg 


Cache; 


Reg 


Invert 




Invert 




Invert 




AdrA3 




AdrAS 




AdrA3 





(Merge CPU Data with Data Reg) 
-►I CPU Write OEf#- 
Data Reg 0,E. 



Update 
Date 
Cache 



CPU Bus 

Intrtfoce 

Cntis 



k-cpu ^ 
Adr strobe 

|Retr/ 
to 

CPU 



CPU 
Adr Strobe 



Ack 
to 

CPU 



FIG. 8 



14/23 



rarhe Read Mtc;<; - Best Case Timing 



States 



nnu 



rmniuuiiiiuirinru 



TrenloteCPU 
VlrtAddr. 



I I I I 



Translate Cache 
VlrtAddr. 



I I 

_ TrmtoteCPU 
^ VirtAddr. 



CochaTog 

riQt 



VA rigt. 



MUX Sel 
VAR / VA 



Cache Miss 
Read 



h Cache J 
TagO.E. ^ 



CPUVAO.E, 



I Cache I Clk 
Hit/ TagVA 
Miss? to VAR 



Clk RA| 
toRAR 



MUX Sel CPUVA — 



r cpu -H k- 
ReadOE 



Update 



lUpdote 
Tog 
Valid 



ClkRA 
ItoRAR 



|cpuv/J 

|toVAR| 



MUX Sel VAR 



Cache Data O.E. 



Clk 
IWrtBk 

Bfr; 
Invert 
VWrA3 



Clk 
IWrtBkl 

Bfr: 
Invert 
VWtAS 



-^CRUReedOE |4- 
Data Reg O.E. - 



Clk 
Data 
Reg 



Update 
Data 
Cache; 
Invert 
AdrA3 



Clk 
Data 
Reg 



Update 
Data 
Cache 



CPU Bus 
intr trace 
Cntis 



U-CPU -n 

Adr strobe 

|Retr/ 
to 

CPU 



CPU 
Adr Strobe 



Ack 
to 

CPU 



CPU 
Latch 
Data 



FIG. 9 



15/23 



2210480 



Block Reod Ct|cle 
Date B«9 (63:0> 

CPU Ctitrtis 

Mdr Strobe 

Data Ack 0 

DetaAckl 
Memory Controls 

MdrAck 

Data Strobe 0 
Data Strobe 1 

Write Bacic C i fcle 
Data Bu9 (63 



Memoru Dotn Bus 

from CPU From Mem From Mem 




A(Wr(27 



^ . ^Data (64^ ^— ^ata (64) 




FIG. lOa 



From CPU 



From CPU 



From CPU 



:0) — ^Addr (ZT^O^ ^Data (64) ^^a (64)^ — 



CPU Cantrola 

Mem Busy 

Addr Strobe 

Data Strobe 0 

Data Strobe 1 
Memory Controls 
MdrAck 



A. 



r 



J 



DataAck 0 



DataAck 1 



\ 



Note: All Control Signals are Neoative Active Siaifcals 



FIG. I Ob 



16/23 

Cache Flush Block Diagram 



2210A80 



CPU Bus Grant 



t lush Command Decode 



CPU VA(31:28) — 
CPU FuncCode (2:0) 
Cycle Decode Timing 



CPU D(1:0) 



CPU A(27:9) 



FIG. II 



Segment Match 
Page Match 
Context Match 



Cache Controls 
Memory Busy 



A(31:2B)»0xA [ 
FC(2:0)-0x3 A 

7 « 
17^ 



► D(1:0K0r 

• D{1:0)=*10* 
D(1:0)-1V 



Clk 



Bus Request 
Logic: 

CPU Grants Bus 
Mastership 
to Start Flush 
State Machine 



D C 



D C 



■ D 



Flush Adr Reg 



52 



50 



A(8:4) 



Context 
Flush 



Page 
Flush 



Segment 
Flush 




Flush Controls 



Flush Match 



Bus Request to CP 
Bus Grant Ack to d 



Flush A(27:9) 



Flush A(8:4) 



Flush Controls 



17/23 



221C4B0 



Virtual Address Cache: 
Cache Hit an d Flush Match Deftnltlon 



Cache Address 

VA(15:4) 

Cache Tags 

CX{2:0) 



VA(27:17) 



VA(16) 




FIG. 12 



18/23 



2210480 



f ]|ugh State Machine: 
Flush Command Decode and DVMA State Machine 




State (c) 



Lotch FludhAddrand 
Tgpeof FlitthCmd 
Assert Bus Request to CPU 
Assert Bus Acknovled^e 
to CPU to end cycle 
Assert Flush Request 



State (e) 



Null 




Request? 



Assert Bus Request to CPU 



N Bus Grant Y 
JromCPU?, 



Assert Bus Grant Ack to CPU 
Deassert Bus Request 




FIG. 13a 



19/23 



Flush Stole Mochfne: 
DVMA State Machine, con't 



( Goto \ 
KEtherTc^ 




Assert Flush Go 
Assert Bus Grant Ack to CPU 



Assert Bus Grant Ack to CPU 
Perform Ethernet Bus Cycle 




Assert Flush Go 
Assert Bus Grant Ack to CPU 



Assert Bus Grant Ack to CPU 



FIG. 13b 



20/23 



221G4B0 



Flush State Machine: 
Flush Compare State Machine 




Assert Flush Request 
Initialize Flush S/M: 
Set Incr Count=0 
for Start Address 
Set Flush Base Adr = 
Flush Cmd Address 
Set Adr bjtA3=0 



Goto (go) 



lncrCnt=lncr Cnt+1 
Fl ush Adr=B8se Adr + 1 ncr 
Assert C«:he Teg OE 
Assert CPUWriteOE 



Flush Go? 



Assert Ceche Tag OE 
Assert CPU Write OE 



Stote (d) 



1^ 



Assert Cache Tag OE 
Assert CPU Write OE 



State (c) FIG. I3c 



21/23 



Flush Stole Machine: 
Flush notch Stole Machine 



2210480 




state 
(g.n) 



State (g) 



MUX: Sel VAR 
Translate Cache YA 
A»«rt CPU VA OE 
Assert Cache Data OE 
CI k Write Back Buffer 
SetAdr b1tA3«1 



State (1) 



MUX: Sel VAR 
Translate Cache VA 
Assert CPU VA OE 
Negate Valid Tag 
Assert Cache Data OE 



State (k> 



MUX: Sel VAR 
Translate Cache VA 
Assert CPU VAOE 
Assert Cache Data OE 
CI k Write Back Buffer 
Set Adr bit A3=0 



State (m) 



MUX: Sel VAR 
Translate Cache VA 
ClkAdrtoRAR (at p) 
Assert CPU VAOE 



State (a) 



Assert Write Back Req 
(to Flush ReqS/M) 



State (q) 




Assert Memory Busy 
Assert Start Write 
Back Cycle 



State (s) 



C 



Goto 
(Idle) 



FIG. 13d 



I 



22/23 



2210480 ' 



fiiiR fi State Machine: 
Flush CornPT""e Stnt fi »^ach1ne. con'l 




FIG. I3e 



V 



23/25 



2210480 



rarhg Flush- Flii«:h Matrh TtnUno 



nimiimuuuuuu 



Stetes 



nnu 



Cache Tag 
M0t 



VA Mgt. 



MUX Sel 
VAR / VA 



Cache Flush 
Match - Load 
Write Back Bfr 



I I I I I 



I I I 

TransleteCK!h8_ 
" VIrtAddr. 



Cache 



U CPUVA O.E. M 

' I Negate! ' 
Valid 
Tag 





TogO.E. 




Incr. 




Flush 


Clk 


Flush 




Match 


TagVA 


Count 




? 


to VAR 



Clk RA 
toRAR 



r- CPU — H K~ 
v^nteOE 



MUX Sel VAR 



Cache Data O.E. 



Clk 




Clk 




Set 


Write Back 


WrtBk 




WrtBk 




Wrt 


Reqd? 


Bfr; 




Bfr; 




Back 


Then set 


Set 




Set 




Req 


Mem Busy; 


A3-I 




A3-0 






Start W/B 



FIG. 14 



- 1 - 

FLUSH SUPPORT. 



2210 

pTTMMM^Y OF rn? jyrvBmrov 

ThiB invention is directed to certain hardware and 
software improvementB in workstations which utilize virtual 
addressing in multi-user operating systeBs with write back 
caches, including operating systeins which allow each user to 
have multiple active processes. In this connection, for 
convenience the invention will be described with reference 
to a particular multi-user, multiple active processes 
operating system, namely the Unix operating system. 
However, the invention is not limited to use in connection 
with the Unix operating system, nor are the claims to be 
interpreted as covering an invention which may be used only 
with the Unix operating system. 

in a Unix based workstation, system performance may be 
improved significantly by including a virtual address write 
back cache as one of the system elements. The present 
invention describes an efficient scheme for supporting data 
protection and the reassignment of virtual addresses within 
such a system. The invention features support for multiple 
active processes, each with its own virtual address space, 
and an operating system shared by those processes in a 
manner which is invisible to user programs. 

cache "Flush" logic is used to remove selected blocks 
from the virtual cache when virtual addresses are to be 
reassigned. If a range of addresses (a virtual page 
address, for example) is to be reassigned, then all 
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instances of addresses from vlthln this range must be 
removed, or "flushed", from the cache before the new address 
assignment can be made. A cache block is "flushed" by 
invalidating the valid bit in its tags and witing the block 
back to memory, if the block has been modified. The "Flush" 
logic includes logic to identify "Flush" commands within 
"Control Space"; logic to match particular virtual address 
fields, within a Flush command, to corresponding virtual 
address fields either within the cache's block address space 
or its tag virtual address field; and (optional) logic to 
flush multiple cache block addresses as a result of a single 
"Flush" command issued by the CPU (or DVMA device, if 
allowed) . It also includes logic to invalidate the cache 
valid tag on matching cache blocks and logic to enable 
modified matching blocks to be written back to memory. 

The present invention includes both hardware and 
specific "Flush" commands inserted within thfe operating 
system kernel. 

pPTEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a block diagram showing the main components 
of a workstation utilizing virtual addresses with write back 
cache. 

Figure 2a is a schematic diagram of cachis "hit" logic 

25. 
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Flgurfi 2b is a acheaatic diagraa of a circuit for 
detecting a cache protection violation. 

Figure 2c is a schenatic diagram of a circuit fcr 
detecting a KMU protection violation, 

7igura 3 is a detailed block diagraa showing the 
address path utilized by the virtual address cache of the 
present invention. 

Figure 4 (4(a), 4(b)) is a flow diagram of a ctate 
machine implementation for certain controls related to the 
addressing of a virtual address write back cache. 

Figure 5 is a detailed block diagram shoving the data 
path utilized by the virtual address path of the present 
invention. 

Figure 6 (6a, 6b, 6c and 6d) is a flow diagram of a state 
machine implementation for certain controls related to data 

transfers to and from a virtual address write back cache 
(states (a) - (o)). 

Figure 7 is a flow diagram of a state machine for 
implementation for controlling Krita Back bus cycles to 
memory. 

" Figure 8 is a timing diagram for best case timing for 
a cache write miss. 



Figure 9 is a timing diagram for best case timing tor 
a cache read miss.* 

Figure 10a is a timing diagram of the mamory bus cycle 
for performing a block read cycle. 

Figure 10b is a timing diagram of the memory bus cycle 
for performing a write back cycle. 

Figure 11 is a schematic diagram showing the cache 
flush implementation of the present invention. 

Figure 12 is a schematic diagram showing the logic for 
detection of Context Flush Match, Segment Flush Match and 
Page Flush Match. 

Figure 13 (13a - 13e) is a flow diagram of a state 
machine implementation of a cache flush initiated by the 
issuance of a flush command. 

Figure 14 is a timing diagram for a cache flush. 

DETATLED DESCRIPTION OF THE INVENTION 

Figure 1 shows the functional blocks in a typical 
workstation using virtual addresses in which the present 
invention is implemented. 

Specifically, such a workstation includes a 
microprocessor or central processing unit (CPU) 11, cache 
data array 19, cache tag array 22, cache bit comparator 25, 



.emory »anage»ent unit (HMD) 27, .ain memory 31, write back 
buffer 39 and workstation control logic 40. Such 
workstations Bay, optionally, also include context ID 
register 32, cache flush logic 33, direct virtual aeBory 
access (DVHA) logic 35, and aultiplexor 37. 

in the present invention, various changes are aade to 
cache flush logic 33, cache hit comparator 25 and 
workstation control logic 4Q which improve the performance 
of a virtual address write back cache. 

p,.^^f pl-<r>n of ye r-«»«^>.T-v ElemPT^I-B of WorkstatlPTl 

CPU 11 issues bus cycles to address instructions and 
data in memory (following address translation) and possibly 
other system devices. The CPU address itself is a virtual 
address of (A) bits in size which uniquely identifies bytes 
of instructions or data within a virtual context. The bus 
cycle may be characterized by one or more control fields to 
uniquely identify the bus cycle. In particular, a 
Read/write indicator is required, as well as a -Type" field. 
This field identifies the memory instruction and data 

address space as well as the access priority (i.e., 

-supervisor" or "User" access priority) for the bus cycle. 

A CPU vhich may be. utilized in a workstation having virtual 
. addressing and capable of supporting a multi-user operating 

Bysteift is a MC68020, 
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Another necessary element in a virtual address 
worXBtation with write back cache shown in Figure 1 is 
virtual address cache data array 19, which is organized as 
an array of 2^ blocks of data, each of which contains 2" 
bytes. The 2M bytes within each block are uniquely 
identified with the low order M address bits. Each of the 
2^ blocks is uniquely addressed as an array element by the 
next lowest H address bits. As a virtual address cache, the 

(H+H> bits addressing bytes within the cache are from the 
virtual address space of (A+C) bits. (The (C) bits are 
context bits from optional context ID register 32 described 
below.) The (N+M) bits include, in general, the (P) 
untranslated page bits plus added virtual bits from the 

(A+C-P) bits defining the virtual page address. 

Virtual address cache data array 19 described herein is 
a "direct mapped" cache, or "one way set associative- cache. 
While this cache organization is used to illustrate the 
invention, it is liot meant to restrict the ecope of the 
invention which may also be used in connection with multi- 
vay set associative caches. 

Another required element shown in Figure 1 is virtual 
address cache tag array 23 which has one tag array element 
for each block of data in cache data array 19. The tag 
array thus contains 2^ elements, each of which has a Valid 
bit (V) , a Modified bit (M) , two protection bits (P) 
consisting of a Supervisor Protect bit (Supvsr Prot) and a 
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Write Allowed bit, and a virtual address field (VA, and 
optionally CX) as shown in Figure 3. The contents of the 
virtual address field, together with low order address bits 
used to address the cache tag and data arrays, uniquely 
Identify the cache block within the total virtual addrcsa 
space of (A+C) bits. That is, the tag virtual address field 
aust contain ((A+C) - (M+N)) virtual address bits. 

Cache "Hit" logic 25 compares virtual access addresses 
with the contents of the virtual address cache tag address 
field. Within the access address, the lowest order K bits 
address bytes within a block? the next lowest N bits address 
a block within the cache; and the renaining ((A+C) - (M+H) ) 
bits conpare with the tag virtual address field, as part of 
the cache "hit" logic. 

The cache "hit" logic aust identify, for eysteniB with a 
shared operating systea, accesses to user Instructions and 
data, and to supervisor instructions and data. A "hit" 
definition which satisfies these requirements is illustrated 
in Figure 2a which comprises comparators 20, AIID gate 22, OR 
gate 24 and AND gate 26. 

MMU 27, which translates addresses within the virtual 
space into a physical address, is another required element. 
MMU 27 le organized on the basis of pages of size {2^) 
bytes, which in turn are grouped as segments of size (2S) 
pages. Addressing within a page requires (P) bits. These 
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(P) bits ere physical address bits vhich require no 
translation. The role of «MU 27 Is to translate the virtual 
page address bits ((A+C-P) or (A-P)) into physical page 
addresses of (MM) bits. The composite physical address is 
then (MM) page address bits with (P) bits per page. 

MMO 27 is also the locus for protection checking, i.e.. 
comparing the access bus cycle priority with the protection 
assigned to the page. To illustrate this point, there are 
two types of protection that may be assigned to a page 
namely, a Supervisor/User access designator and a Write 
protect/write Allowed designator. Although the subject 
invention is not limited to such types of protection, given 
this page protection, a "Protection Violation" can result if 
either a "User" priority bus cycle accesses a page with 
-supervisor" protection, or if a -Write" bus cycle accesses 
a page with a "Write Protect" designation. 

The application of KMU protection checking through the 
W« is shown in Figure 2c which comprises inverter 28, AND 
gates 30a and 30b, OR gate 34 and AKD gate 36. In addition, 
with a virtual address write back cache, the concept of 
protection checking can be extended to cache only CPU cycles 
which do not access the KMU. Such cache only protection 
logic IB shown in Figure 2b comprising inverter 42. AND 
gates 44a and 44b, OR gate 46 and AND gate 48. 
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Also Bhovm in Figure 1 is aain aenory 31 vhich is 
addreseabl3 within the physical address space; control or 
aain aeaory access is through workstation control logic 40. 

Write back buffer 39 is a register containing one block 
of cache data loaded from cache data array 19. Write back 
buffer 39 is loaded whenever an existing cache block is to 
be displaced. This aay be caused by a need to update the 
cache block with new contents, or because the block aust be 
flushed. In either case, in a write back cache, the state 
of the cache tags for the existing cache block determine 
-uhethev this block aust be written back to aeaory. If the 
tags indicate that the block is valid and aodified, as 
defined below, then the block contents aust be written back 
to aeaory 31 when the cache block is displaced. . Write back 
buffer 39 temporarily holds such data before it is written 
to memory. 

Workstation control logic 40 controls the overall 
operation of the workstation elements shown in Figure 1. In 
the preferred embodiaent, control logic 40 is impleaented as 
several state aachines which are shown in Figures 4, 6, 7 
and 13 as will be described aore fully below in conjunction 
with the description of cache flush logic 33, portions of 
which Bje also, in the preferred embodiaent, integrated into 
the workstation control logic. 

Description of Opt<on>.i ^lA ments of Workstatlnt^ 



- 10 



context ID register 32 is an optional external address 
register which contains further virtual address bits to 
identify a virtual context or process. This register, 
containing C bits, identifies a total of (2**C) active user 
processes; the total virtual address space is of size 
2** (X+C) 

An iBportant component in this virtual address space of 
2**(A+C) bits is the address space occupied by the operating 
system. The operating system is cojnmon to all user 
processes, and so it is assigned to a common address space 
across all active user processes. That is, the (C) context 
bits have no meaning in qualifying the addresses of pages 
within the operating system. Rather, the operating system 
is assumed to lie within a common, exclusive region at the 
top of the (2**A) bytes of virtual address space for each 
active context. No user pages may lie within this region, 
so the operating system page addresses for two distinct user 
processes are identical, while the user pages for the two 
processes are distinct. All pages within the operating 
system are marked as having "Supervisor" protection. 

cache flush logic 33 is also an optional element in a 
workstation. However, cache flush logic 33 is included, and 
modif le'd as described in detail below in order to improve 
the performance of a virtual address, write back cache 
system. Briefly however, cache flush logic 33 operates as 
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follows. If ft range of addresses (a virtual page address, 
for example) is to be reassigned, then all instances of 
addresses fron within this range must be removed, or 
"flushed", from the cache before the new address ftssignaent 
can be made. X cache block is "flushed" by invalidating the 
valid bit in its tags and writing the block back to memory, 
if the block has been Bodified. 

In addition to CPU 11 as a source of bus cycles, the 
workstation may include one or more esetemal Input/Output 
(1/0) devices such as DVHA logic 35. "These external I/O 
devices are capable of issuing bus cycles which parallel the 
CPU in accessing one or more "Types" of virtual address 
spaces. The virtual address from either the CPU 11 or DVMA 
logic 35, together with the address in context ID register 
32, is referred to as the access address. 

Another optional element is data bus buffer 37, which 
in the preferred embodiment is implemented as two buffers to 
control data flow between a 32 bit bus and a 64 bit bus. 
such buffers are needed when the CPU data bus is 32 bits and 
the cache data array data bus is 64 bits. 

p^.>. T.4p^-4on of El ^ inpnl^e Pntmie to the Invented Vor};ptation 

in the present Invention, the definition of a cache 
"Hit" is modified to take into account the use of a shared 
operating system across multiple active user contexts, and 
the access priority and page protection. By so doing, an 
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efficient indication of a protection violation within the 
vrite back virtual address cache can be achieved. 
Specifically, to implement the protection definition 
presented above, the following cache -Hit" definition is 
utilized. 

A cache "Hit" has three requirements: 

1) The cache block must be marked as having valid 
contents . 

2) Ignoring the (C) context bits, the access virtual 
address bits (A-(N+M)) must match the corresponding tag 
virtual address field bits (A-(H+H)), at the cache 
block addressed by the (N) bus access bits. 

3) Either the (C) bits of the access context ID must 
match the corresponding (C) context bits in the cache 
tag virtual address field, or the cache tag Supervisor 
protection bit must be set active. 

^ This definition of a cache "Hit" enables cache 

protection checking to be applied directly to the virtual 
address cache, rather than defined through an MMU check 
during cache miss handling, h "Protection Violation" on a 
cache "Hit" results: 

1)' if the access bus cycle has "User" priority and the 
cache block has "Supervisor" protection; or 



2) if the access is" « Write bus cycle and the cache 
tlock has Write Protection. 
An implementation of cache hit detector 25 according to the preser 
invention is shoun in Figure 2a described hereinabove. 

The present Invention utilizes a set of "Flush" 
coBBands in the Control Space to efficiently inplement 
virtual address reassignment In a virtual address write back 
cache. 

In general, Plush coamands are bus cycles in Control 
Space which specify, for each unique type of Flush command, 
one or aore virtual address fields to be compared vith 
corresponding virtual address fields, in the- virtual address 
cache tags. "Matching" address fields cause the hardware to 
"flush" the cache block. To "jflush" the cache block means 
that; 

1) X matching cache block that is marked as both 
"Valid" and "Modified" is written back to memory. This 
requires a cache block "write back" bus cycle to the main 
aemory. A "write back" bus cycle writes the contents of an 
entire cache block Into main memory at the appropriate 
physical address. As a part of this cycle, the virtual 
address, identifying the cache block la translated through 
the MOT* Into a physical aemory address. During this 
translation, protection checking for the cache block Is 
inhibited. The address translation through the MMO lo 
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connleted prior to returning control to the procesBor at the 
conclusion of the flush coxnnand. 

2) Any matching cache block that is "Valid", whether 
"Modified" or not, is marked as invalid. 

jiB described, the "write back", bus cycle requires the 
translation of the cache block virtual address into a 
physical address. The concept of the flush command and 
"write back" bus cycle can also be extended to virtual 
address caches which contain both virtual address and 
physical address tag fields. If a physical address tag 
field is present, no translation is required at the time the 
"write back" bus cycle to main memory is performed. 
However, the present invention is directed to the use of 
virtual address tags to support a virtual address write back 
cache . 

The flush command as described above applies to a 
single cache block. The application of the flush command 
can also be extended so that a single flush command 
activates hardware which checks multiple cache blocks, 
flushing those blocks which match the address fields of the 
flush command. It is only required that the address 
translation of the last cache block flushed be concluded 
prior €o returning control to the processor at the 
conclusion of the command. 



Three specific flush commands are defined below. While 
other similar commands may be defined, these three are 
particularly useful in effectively restricting the scope of 
a "Flush" command to a minimal address range. These "Flush" 
commands are also effective in implementing a multiple 
context, shared operating system address space. 

1, Context Match Flush Command - 

The Context Match Flush command flushes from the cache 
all cache blocks within a specified context which are from 
User protected pages. It specifies a context identifier of 
(C) bits. The match criteria is to require first, that the 
cache tags Identify the blocX as having User protection; and 
second, that the (C) bit field of the Flush command match 
the corresponding (C) bit Context identification field of 
the tags. 

The Context Match Flush command is used to ensure cache 
addressing consistency whenever a new active context 
replaces an old context in the MMU. The Context Match Flush 
must be performed before the old context references are 
removed from the MMU, since the MMU is required to translate 
the cache blocks' virtual addresses. 

2.;Page Match Flush Command 

The Page Match Flush command flushes from the cache all 
cache blocks within a specified page, regardless of the page 
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protection. It opeclfles a page tiddrcBS of (A+C-P) bits. 
The Batch criteria is to regiilre that first, the (A-P) bit 
field of the Flush comand, vhich identifies a virtual page 
addrfeBS within a Context, aatch the corresponding (A-P) bits 
to identify the virtual page address of a given cache block. 
These (A-P) bits aiay be in the cache tag virtual address 
field or in a combination of both the cache access address 
and the cache tag virtual address field, depending on the 
page size and the size of the cache. 

The second aatch criteria is to require that one of the 
following two conditions is net: i) the cache block's 
Supervisor access protection tag is active; or ii) the 
context ID register of (C) bits aatch the cache block's 
corresponding Context ID tag field of (C) bits. 

The Page Match Flush conmand is used during page 
nanagement to purge all references to a virtual page - with 
either Supervisor or User protection - from the cache. It 
must be performed before the KHU is updated to remove the 
page, since the MHO is required to translate the cache 
blocks* virtual addresses. 

3. Segment Match Flush Command 

The Segment Match Flush command flushes from the cache 
all cache blocks within a specified segment, regardless of 
the page protection. It specifiqs a segment address of 
((A+C)-(P+S)) bits, since the segment site is (2**B) pages. 
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The Batch criteria is to require that firet, the (A-(P+S)) 
bit field of the Flush coBmand, which identifies a segment 
within a Context, Batch the corresponding (A-(P+S)) bite 
identifying a segment for a given cache block* These (A- 
(P+S)) bits Bay be in the cache tag virtual address field or 
in a combination of both the cache access address and the 
cache tag virtual address field, depending on the segment 
size, the page si^e, and the size of the cache. 

The second match criteria is to require that one of the 
following two conditions is met: i) the cache block's 
Supervisor access protection tag is active; or ii) the 
context ID register of (C) bits match the cache block* s 
corresponding Context ID tag field of (C) bits. 

The Segment Match Flush command is used during page 
management to purge all references to a virtual segment - 
with either Supeirvisor or User protection - from the cache. 
It may be required, depending on the structure of the KMU, 
whenever the pages of an entire virtual segment must be 
reassigned to a new virtual segment. It must be performed 
before the KMU is updated to remove the segment mapping, 
since the KMU is required to translate the cache blocks" 
virtual addresses. 

Flush Command Usage 

The three "Flush" commands defined above, together with 
the respective "match" criteria, are executed only by tlie 
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operating Byetea vithln the Unix kernel. The placement of 
flush cojuaands within the kernel le described within 
Appendix A. By proper placement of "Flush" commands within 
the kernel, virtual address reassignment for a Unix system 
may be implemented to support a virtual address write back 
cache. 

The set of flush commands defined above, when used in 
the Unix kernel as shown in Appeiidix A, implement a 
mechanism to support virtual address reassignment, as 
required by a virtual address cache, for a Unix system with 
multiple active contexts and an operating system shared 
across those contexts for workstations having cither write 
through or write back caches. 

The flush commands,, when used in the Unix kernel as 
shown in Appendix A, support a virtual address write back 
cache within a Unix system so that the use of such a cache 
is transparent to user application programs. Ko changes are 
required to user programs to take advantage of the memory 
speed improvements inherent in a virtual address write back 
cache. 

Additionally, the flush commands, when used in a Unix 
kernel as shown in Appendix A, support a virtual address 
write* back cache implementation which contains only a 
virtual address tag field for block identification, not a 
physical address tag field. Avoiding the addition of a 
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physical addresB tag field ainioizes the nunber of cache 
tags required for the virtual address write back cache. A 
write back cache requires that at Bone point, any cache 
block which has been modified must be written back into main 
aemory. This "write back" operation may take place either 
when the cache block is replaced by new block contents (the 
normal block replacement on a cache "miss") , or when the 
cache block is flushed prior to reassigning a range of 
virtual addresses containing this cache block. 

If the cache tags contain no physical address field, 
then the virtual address tags must be translated into a 
physical address before the cache block aay be written into 
memory. In the case of cache flushes, this implies that all 
address translations of cache block virtual address fields 
which result from a flush match must be completed prior to 
the operating system's reassignment of the virtual address 
range within the KMU. Two features of the invention are in 
part responsible for ensuring that this requirement is met: 

1) first, that the flush command requires the 
completion of the cache block virtual address translation 
before control is returned to the processor? 

2) and second, that the flush commands are structured 
in the kernel, as shown in Appendix A, at strategic 
locations which guarantee the flushing of all modified cache 
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blocks prior to the reassignment of the virtual address 
rzmge. 

The set of three flush cosimands defined above, together 
vith . their respective •«aatch" criteria, constitute an 
efficient virtual address rcassignnent TOChanism when placed 
in the Unix kernel as shown in Appendix A. The aechanisa is 
efficient in that it optimizes flush performance for the 
virtual address write back cache for the three cases of 
virtual address reassignment required by the operating 
system: 

1) whenever an existing active context is being 
replaced by a new context; 

2} whenever KKU limitations require the reassignment of 
a currently mapped segment to a new segment; and 

3} whenever a physical page in memory is to be 
reassigned to a new virtual address. 

The three flush commands are defined, together with the 
flush match criteria, to specifically cover each of these 
cases. Flush commands are issued by the kernel by starting 
at a base block address, and then incrementing block 
addresses so as to check every block within a fixed address 
range. -The flush commands as defined are efficient in 
address reassignment for two primary reasons: 
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1) The flush match criteria restrict the number of 
blocks flushed to be only those blocks vhich require 
flushing vithin the flush address range. Other extraneous 
addresses, outside the flush range, are checked but are not. 
flushed. 

2} For each of the three cases requiring address 
flushing, the defined flush commands allow the cache to be 
checked with a single pass through the appropriate cache 
block address range. For example, to flush a segment, every 
page vithin the segment must be flushed. If a segment flush 
vere not implemented, then multiple passes of page flusH 
commands vlth varying page addresses might be required to 
complete the segment flush. 

The preferred embodiment of the virtual address cache 
for the address path Is shown in Figure 3 and for the data 
path is shown in Figure 5. Flush control logic in the 
preferred embodiment is implemented as showxl in Figures 11, 
12, the state machine of Figure 13 and timing diagram of 
Figure 14. A best case timing diagram for writes is shown 
in Figure B and for reads is shown in Figure 9. 

In addition to components previously discussed vlth 
reference to Figure 1, Figure 3 Includes virtual address 
register (VAR) 5^ which stores the current virtual address. 
The elements of the invention appear in Figure 3 are cache 
flush logic 33, the Protection bits (P) in the cache tag 
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array 23, and the flush aatch logic 24 «^ich is part of cache hit 
detect log 25. 

Also shown in Figure 5 is data register 61 which stores 
data to be -written to or which has been read froa memory 31 
or cache data array 19* 

In Figures 2, 3, 5, 11 and 12, to avoid \innecessarily 
cluttering the Figures, not all control lines are shown. 
However, the control lines necessary for proper operation of 
the invention can be ascertained from the flow chart of the 
state machines shovn in Figures 4, 6, 7 and 13, and timing 
diiigrams shown in Figures 8-10 and 14. 

In the flow charts, the following abbreviations are 
utilized: 

MUX - multiplexor 45 
Sel ~ select 
VA - virtual address 
RA real address 
0£ r output enable 
Ack - aclcnowledge 
Cache Hit? - Did cache "hit" logic 25 

detect a cache hit? (Fig 2a) 
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Cache Protect Violation ? - Did control logic 40 detect a 

detect a cache protect violation? 
(Fig 2b) 

Memory Busy? - Has Kemory Busy been asserted? 
KKU Protect Viol? - Did control logic 40 detect a 

HMU protect violation? 
(Fig 2c) 

RAR - real address register 51 
CLK - clock 
Adr - address 
Mem Adr Strobe - memory 31 address strobe 

VAR - virtual address register Sk 
Mem Adr Ack? - Has a memory address acknowledge 
been asserted by memory 31? 
Mem Data Strobe 0? - Has memory data strobe 0 been 

asserted? 

Mem Data Ack 0? - Has memory data acknowledge 0 been 

asserted? 
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Kern Date Strobe 1? - Has aeaory data strobe 1 been 

'asserted? 

Ken Data Ack 1? - Has nenory data acknowledge 1 been 

asserted? 

'dk Write Back Buffer - clock write back buffer 39 
CPU Read cycle? - Is CPU 11 in a read cycle 
Clk Data Reg - clock data register 61 
valid and Modified Write - Has control logic 40 detected . 
Back Data? bit{W) and Modified bit(M) 

Start write Back Cycle? - Has control logic 40 asserted 

Start Write Back Cycle 

Similar abbreviations are used in the timing diagrams 
of Figures 8-10 and 14. 

The address state nachine shovm in Figures 4a and 4b 
defines certain of the controls related to the address 
handling portion of cache 19. The cache tags 23 are written 
as valid during state (w) , following a successful transfer 
of all block data from aenory 31. The invention is 
integrated through- the inclusion of the Cache Protection 
Violation test following state (c) . If e Protection 
Violation is found on a cache Hit, then the CPU bus cycle is 
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terminated itmedlately with a Bus Error response to the CPU. 
•The MMU Protection Violation on the translated address is 
performed later, following state (g). 

The data state aachine shown in Figures 6a - 6d define 
certain controls related to the data transfer portion of the 
cacne. Again, the invention is supported by including a 
test for the Cache Protection Violation following state (c) . 
The MMU Protection Violation test on the translated address 
is siffiilarly performed in state (g) . 



The write back state machine shown in Figure 7 defines 
the control of the Write Back bus cycle to memory. This 
cycle may be performed in parallel with CPU cache accesses, 
since both the Write Back controls and data path are 
Independent of the cache access controls end data path. As 
described below, the "Memory Busy" signal causes the address 
and data state machines to wait until a previous Write Back 
cycle has completed. 

The write cache miss timing diagram shown in Figure 6 
defines the overall timing of a CPU write bus cycle to 
memory which misses the cache. The cache Hit and 
Protection Check occur in cycle (c) in this diagram. 

A part of the miss handling sequence includes the 
loading of the current cache block which is being replaced 
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Into write back buffer 39 In cyclee (i) and (m) . The 
translated address for the current cache block le also 
loaded into real address register 51 in cycle (o) . If the 
current cache block is both Valid and Modified from a 
previous CPU (or DVMA) write cycle, then this cache block 
will be writtten back to aenory 31 through a Write Back bus 
cycle, described in both the Meaory Data Bus timing and the 
write Back state machine, Figures 10 and 7 respectively. 

The CPU write data is merged with block data 
returned from memory on the first data transfer of a 
Block Read memory bus cycle. During cycles (q) through 
(u) , the CPU write Output Enable controlling buffers 37 
will be active for only those bytes to be written by 
the CPU, while the Data Register Output Enable 
controlling data register 61 will be active for all 
other bytes. During the second data transfer, cycle 
(w) , the Data Register Output Enables for aU bytes 
will be active. 

The read cache miss timing diagram shown in Figure 9 
defines the overall timing of a CPU read bus cycle to a 
cacheable page in memory which misses the cache. The cache 
Hit and Protection Check occur in cycle (c) in this 
diagram. 

X part of the miss handling sequence includes the 
loading of the current cache block which is being replaced 
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into write back buffer 39 in cycles (i) and (m) . The 
translated address for the current cache block is also 
loaded into real address register 51 in cycle (o) . If the 
current cache block is both Valid and Modified from a 
previous CPU (or DVMA) vrite cycle, then this cache block 
will be writtten back to aenory 31 through a Write Back bus 
cycle, described in both the Memory Data Bus Timing and the 
Write Back State Machine, Figures 10a and b and 7 respectively. 

Data is read to the CPU by simultaneously bypassing the 
data to the CPD through buffers 37 enabled by control signal 
CPU Read Output Enable, active in states (q) through (u) , 
and updating the cache, in state (s) . The memory is designed 
to always return the "missing data" on the first 64 bit 
transfer, of a Block Read memory bus cycle and the alternate 
64 bits on the subsequent transfer. After the CPU read bus 
cycle data is returned, the CPU may run internal cycles 
while the cache is being updated with the second data 
transfer from memory. 

The Memory Data Bus timing shown in Figure 10a and 10b. 
■hows the timing of Block Read and Write Back bus cycles. 
Since the cache block size is 128 bits, each cache block 
update requires two data transfers. As indicated above the 
64 bit8_ containing the data addressed by CPU 11 are always 
returned on the first transfer for Block Read bus cycles. 
The "Memory Buey" control signal active during the Write 
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Back cycle is used to inhibit the start of the next cache 
Bi88 cycle until the previous Write Back cycle can complete. 

cache flush logic 33 shown in Figure 11 outlines the 
control end data path of the flush controller. Ihis 
controller iaplements the cache flush operations of the 
present invention for a systen with multiple active user 
contexts and a shared operating system. Cache flush logic 
comprises AND gate 48. flip-flops 49, flush address register 
52, incrementer 50, AND gates 55 and OR gate 58. 

Three flush match signals ere used by cache flush logic 
33 to determine whether the addressed cache block is to be 
flushed, corresponding to the three flush match signals are 
three flush commands issued by the CPU. A Plush Match is 
said to occur if: 

(Context Plush Command.) AND (Context Flush Katch Signal) 
OR (Segment Flush Command ) AND (Segment Flush Hatch Signal) 
OR (Page Flush Command) AND (Page Flush Hatch Signal) . 
An implementation of such flush match logic is shown in 

-Figure 12 comprising comparators 60, AND gate 62, Inverter 

64, OR gate 66 and AND gates 68. 

Flush control logic 33 involves two distinct phases, 
which are shown as separate sequences in the flush state 
machine'. Figure 13. The first phase involves decoding a 
Flush command from the CPU and obtaining bus mastership for 
the Flush Control State Machine. The Flush command is 
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l«su«d by the CPU in Control Space (identHled by Function 
code blto TC(2»0)-0Jt3). Kithln control Space, the four high 
order address bits A(31:28)-05CA indicate the Plush command. 
The addreso field X(27:0) tor the command correspond to the 
38 bit virtual address field for data accesses. IPhe Plush 
command data bits D(1:0) encode the type of flush. After 
the Flush command is decoded, the address field A{27s9) is 
latched together with the type of flush. A Bus Request 
•ignal is asserted to the CPU to obtain bus mastership. 

The second phase involves performing DVMA cycles to 
test end flush, if necessary, 32 cache blocks using cache 
flush logic 33 as a DVMA device. This DVHA device addreBsee 
cache blocks with the virtual address A(27:9) captured from 
the flush command, plus address bits A(8:4) from an internal 
5 bit flush address counter 60. Each cache block may be 
checked in three cycles, with the three Plush Match slgnale 
gated by the Plush command latches 65 to determine a "Flush 
Hatch" condition. A "Flush Match" results in the cache 
block being invalidated and e Modified block being written 
to memory through the Write Back state machine. Following 
the conclusion of the 32 block check, bus mastership may be 
returned to the CPU. 

Kote that as a DVMA device, the cache flush logic 33 
competes with othei DVMA devices for bus ownership. Of the 
possible three DVMA devices, Ethernet (not shown) has the 
highest priority; the cache flush logic 33 eeeond priority; 
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and VMEbUB devices third.' The flush control state aacbine 
does not include a conplete arbitration description for all 
DVMA. devices, but rather only logic related to the Flush. 

The cache flush state machine Bhown In Figure 13 
coaprises four interacting aachines which control the flush 
operation. These four nachines control the decode of the 
CPU Flush coninand and its application to 32 cache blocks. 
The four aachines ere described below: 

1) The Cojmaand Decode aachine decodes the Flush conmand 
executed by the CPO. Upon decoding a Flush conaand, 
the flush virtual address A{27:») and the type of Flush 
coaanand are latched. The aachine asserts a Bus Request 
to the CPU to obtain bus aastership for the flush state 
aachine. It also asserts a Flush Request signal to 
activate the DVMA aachine, below. 

2) The DVMA aachine obtains bus aastership froa the 
CPU, as indicated by the CPU's asserting Bus Grant, and 
holds aastership by asserting Bus Grant Acknowledge. 

It arbitrates the Flush with the higher priority 
Ethernet requests. 

3) The Flush Coapare aachine initializes its address 
cojonter A(8:4) to 0 with the Flush Request, signal . It 
continues to check cache blocks as long as Flush Go is 
asserted by the DVMA aachine. Khen Flush Go is 
deasserted, a Flush Done signal is set at the 
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conclusion of the current block flush, vhlch signals 
the DVKA machine to grant jnastership to the Ethernet 
handler. If a Flush Match is detected, the Flush Block 
Request signal is asserted to activate the Flush Match 
machine. At the conclusion of the Flush Match machine, 
this machine returns a Write Back Request signal to 
' complete the machine's handling of the current cache 
block. 

4) The Flush Match machine loads the cache data into 
write back buffer 39, clocks the translated cache 
address in real address register 51, and invalidates 
the cache tags 33. Note that no protection check is 
performed. At the conclusion, the Write Back Request 
signal is asserted. If the cache block is marked as 
Modified, the Start Write Back Cycle signal is also 
asserted to activate the write back state machine shown 
in Figure 7. 

Figure 14 shows cache flush timing and describes the 
timing of a block flush in the event of a "Flush Match". 
This condition is tested in state (c). The block is 
Invalidated in state (k) . If the block satisfies the "Flush 
Match" and is Modified, then it must be written back to 
memory. A "Start Write Back Cycle" signal is asserted in 
state (B) to begin the Write Back state machine. 



The kernel changes needed to support the virtual 
address write back cache of the present invention for 
Unix operating system are shown in Appendix A. 



K«»al P-lgn Oocu««t fe« Virt«1 war... ceha 

^* 2!^H5nJ§rl5reo.r.et».« e« th. Virtual " It^ai"** 
caeba In ahlrt)"*. k-'P tha f oUowlnf Invariant condition trua at all 

If an antry la In tha eaeba, ita napping fro» 'vlztnal 
addxaaa to phyaleal addraaa snat ba eexsaet. 

fhla la a attfttelant condition tot tha eesraetnaaa e£ tha ayataa 

•itb thrSehe baing turnad off. Thua, writing la cerraet. 

It la daar that tha abova Invariant condition can ba kapt 
1£ «a £l5ih thS ISastad cacha Una. bifora a virtual to phyaleal 
aAppl&g bttcoMS IneorxftCt* 

no leaa than 50 nderosaconda and a ••B"*?^ 

takea no lass than 400 Bicrosoconds, axduding tha evarhaad 

2) ?lr'dl2lT«ipSrSrtS:i addr...... « both virtual add...... 

can S accessed aimultaneouaXy, they have to ba arranged tc 
SiSeh in their lo« order 17 bits, i.e. "^f'^^^e^JI^ltl 1 • 
described in the 6un-3 Architecture Manual . ©therwiae, l.a. 
1« they are accessed one at a tine, we consider tha 
eurrentlv used mapping correct and other nappings 
iSm«JS a? thi.'^SiJ. That is, the 'Jf"^ 

ether not-currently-used nappings are not In the caene. 

3) Ke lonore the problens e£ reading /dev/mea bacauae 

a) aSSs S /dev/mem la not guaranteed to be conaiatant 
lie!"* aystems without the virtual address cache, 2) aueh 
!dS"j Sneoniietenc. is rdnimal. (because «ost o£ «aagea 
are £or the u areas of non-running processes P*»*» 
III already flushed during centoKt awitchea), 3>^~*i2t,.i 
r«t«n behaves as the system without cache requires the kernel 
?i«^££ the cache of the entire aystem while /dev/nen la opened 

Seans any user process can alow down the entire ayataa 
considerably by open /dev/nem. 

— — xSFfHllSsi'routines are added to the kernel. 



•11 each; liny, irhes* •iqwrvisox hLtB la th« each* tag of £ WD^uI 
X.e, It nuBhaa an aatixa «a»x eontaxt. .«aojBtsflu«h(> la daUaad la 



2!5 f i l!^ v**f J*2*" ••9««'>t addraaa parts (A<1«-27>1b 8im-3) 

ef tba eaeha tag aateli •aegnBat.notfbex- aithax txea a kaxnal Addraaa 
•paea or fren tha earxant naax'a addxasa apaea. x.a. It fluahaa altbax 

wjiagflttahO la daflaad la aap.a. 

_ *fej>iga£lttBhCvlxtualaddia8B) ttaahaa tha ea6ha hy paga-stttdi. 

l\ S2"5L.?i.S*«r.i^J!' whoaa-pag. addxaa. paxta (hKlS'l'lViS^n^) 
fl^l S™i JL"**** P*9« P*«t of •vixtual addxasa" altbax 

4* ifSIi.!*^! ■ "^'f* enxxaat uaax'a aildxass apaea. 

altbax a kaxnal paga ex a uaax page e£ tha euxxaat naax 
eentaxt. vaej>agaf lush () la daflaad la aap.a. cuxxant naax 

»*c_tt«;1;(vlxtnal_addxas8, ambax of bytas) fluibas tba eaeba 

ainas «heaa paga addraaa paxta (A<13.27> In sourarof tha cache tagrSI In 
the xangas of fvlxtual addxasa-, -vlxtual addraaa- ♦ -auatoax of Sta" - 11 
It fluahaa tbeaa llnaa aithex fxem a kamaT addxasa apaea ex ?reBtha 

S'"* '^f_"«»»{) la uaad altbax to flnah laaa 
** «««»na(), ox to flvab a nuaftwr of eoatlguoua 
pagaa, aueh as fxen pagaeut(}. vae.flnsbO la defined la aMp.a. 

vae flttshallO fluahaa tha eatlxe eadie. Zt la uaad to flush 
*ha eatlxe eadia to the phyalcal BMnsxy bafexe we dvap the Syslcal 
awaory from duapsys () . It aay also be uaad aa an digging tSol. 
▼ao.flushalK) Is defined In vnjoachdap.c. • 

. . vae_disable_kpage{vlxtual_addresg) turna off the caching of 

a kernel page atartlng at -virtual address-. It Is used by the device 
driver xnapO routine to enforce tFa consistency of sharing a kernel pace 
with uaar pages, vaejdisablejtpage () la defined In vajnachdep.c. 

7) vac.enable_kpage (virtual addraaa) turns on the eachine of a 
kaxnal page ataxting at -vixtual.adTress-. If a device dxivex nLp 
routine knowa that no nore user pages are aharing a kernel paee. It 
ealla vae_enable kpageO to allow the eaehing of this kernel page. 
vacjsaable_kpageT> la defined In vnjnachdep.e 

XV. Where and how do we flush the cache? 

^* vae,ctx«lusir?r IroHTctxf ree () la va naehdep.e. 

{ Ctxf ree () la called when a context Is freed fron MHD 
and hence the mapping of the whole context le not valid. 
Ctxf ree q la called from ctxallocO when the oldeat 
context la buaped out of MMD, f xoo swapout () when a 
process Is swapped out, fron exitO when a preceaa 
la teminated, and from ptei^and () when thia context 
Z* '^y?" b«for« Ita pte'a axe expanded. ) 
' *• vac^ctxfluahO from vrelvm() In vjnproe.e. 

t Vrelvml) xeleasea the vm xesoarces associated with thia 
pfcoeeas. Shis will eausa all vixtual and physical pages of 
the process be releaaed and thus invalidate, all vixtual to 
physical aappings of the current context. » 
»*• efll vae_ctx£luah« fxem expand () In vm oroe.e. 
{ This happena when a proeeas Is shrinking and it eivea back 
eons vixtual memory. ) • »•« 

41 *» ctXX vaejBtxflushO from ovadvlseO In kern anan.e. 

{ Wian the paxaraeter to vadviseO Is VA_n.PSB,""we Invalidate 
all page table entries of the ourrent process. A eeatext flush 
£■ ""f? •«ficient than a number of page flushes. , 
* V*^^ *2 'wmpnegreleaseO In vm maehdep.e 

f taeareleaseO la called when a pnaq Is taken away. 



Pmgzel^aseO eu be emiled by either pnegalloeO or 

pi&egAllocreB 0 • } 
€) He call vac eegfluibO from poiBgloadO in ir&Mehdep.e. 

( A aegnent'^ln the bole is to be freed and set to SEGZHV 

in the eegment up. ) . 
7} We call vac pagef lush 0 f rem pageout () in vapage.e. 

I This is When a page is autcted invalid by the pageoot 

demon. } 

8) Ve call vac page flush () from ovadviseO in kem^onan.e* 
( This is wEen ovadviseO narks a page invalid. } 

9) We call vac pagef lush () from napout () of vmj&aehdep.e. 
( MapoutO Is called to release a mapping from kernel 
virtual address to physical address. 

KapoutO is called froms 

e) physstrat () when mapping from kernel virtual address to 

user buffer address is released. • 
I}) memfreeO 

c) cleanup 0 

d) ptexpandO to release old page tables. ) 

10) We call vac^ageflttshO from pagenoveO of vm^maehdep.c. 

( In pagemoveO tre call vae^age£lush(to) because the mapping 
of "to* to its physical page is .not valid after setpgmapO call. 
We call vac^pagef lush (from) because the mapping of "from" 
to the physical page is net valid after the second 
setpgmapO call. } 

11) We call vac^pagef lush 0 from abrelseO of sundev/ab.e. 

( This is vhen setpgmap(addr, 0) is called to invalidate 
the mapping from X>WA virtual addresses to physical 
addresses. ) 

12) We call vac^flushO from resumsO in vax.s. 

( At the end*"of context switch time# the mapping of the 
outgoing process's u becomes invalid. We should flush 
the outgoing process's u before its u mapping becomes invalid. 
Since context switch happens very frequent, we only flushes 
the user struct and the kernel stack , instead of flushing 
the entire u page. (Resume () is also called from proedupO 
to force an update of u.) ) 

13) We call vac_flush() from ssanapOf munmapO« and munmapfdO 
in kern^nmanTc. 

( virtual to physical mappings of some pages are changed. } 

14) We call vac_f lu shall O from dunpsysO of mfchdep.c to 
flush out the content of the entire vac to physical memory 
in order to dunip out the physical memory. 

15) There are a nuinber of places where virtual*to-physical 
mappings are invalidated inplicitly, e.g. the pme/pte mapping 
is still valid but this mapping is never used again. We 
must flush the associated portion of caches otherwise, when 

a new mapping is set up from this virtual address, the 
cache may contain some lines of the previous mapping. 

a) We call vac^agef lush () from nbsetupO of sundev/nb.c. 
{ In sfldsetupO, the mapping from pte's to physical 
pages is teziporarily (until nibrelase) replaced by the 
mapping from DVHA virtual addresses. ) 

b) We csll vac^pagef lush 0 from dumpsys () of maehdep.c. 

1 The last page in the DVMA region is used to map to one 
physical page at a time to dunp out the physical memory. 
Such a mapping is invalid each time after (*dumper) () 
is called. ) 

c) We call vac jpagef lush O from physstrat 0 of maehdep.c. 
{ Xn physstrat (), "user" pages are doubly mapped to 
the kernel space. We flush these user pages when we eet 

up the associated kernel pages. Xateri these mappings from 
kernel virtual pages to physical pages are invalidated by 
mapoutO, there these kernel virtual addresses are 
flushed. ) 

d) We call vac paaeflushO from copyseerO of maehdep.c. 



{ Xn eopyaegO, the napping from virtual address CADDRl 
to physical address *pgno* beeooes Invalid after copylaO . 

•) We call vac^sgeflttsh () fromnarwO of eun3/aea.e. 

{ Xn anrwO, the napping fron *vBinap" to a physical address 
is set up to copy physical data to the user space. This 
napping becomes Invalid after uioaove () • ) 

f) We call vac j»agef lush () from page in () in vm page.e. 

( The napping from CADOXa to physical page pf^l becones 
Invalid after bseroO* ) 

g) We call vae_flush(} from proedupO of vmproc.o 

to flush the kernel stack and u * parts of forkutl. 

( Xn procdupO, forkutl naps to^the physical u page 

of the child process through vgetu(). 

Since the napping from forkutl to the physical u page 

of the child becomes Invalid vhen the parent returns fron 

proed^p(), forkutl la flushed before procdupO returns. 

h) Ke call vac_flush() from newprocO of kern fork.c 
to flush the u^* part of vfutl. 

{ Xn newproeO, In the case of vfork# vfutl naps to 
the physical page of the child through uacoessO* 
This napping Is not used anymore after vpassvmO 
Is called. ) 

1) We call vao_flush() from svapoutO of vn svap.o 
to flush the u_* part of utl. 

{ Xn swapoutO, napping from utl, whi^ la either 
xswaputl or xswap2utl# to the physical u page of proe p 
. Is Invalid after proc p is swapped out. ) 
j) We call vacjflushO from swaplnO of vm swap.e 
to flush the u_* part of utl. 

I Xn swapin(),*l&apping from swaputl to the physical 
u page of proc p becomes Invalid before we return from 
avaplnO. ) 

k) We call vac^agef lush () from swapO of vn swp.e. 

{ The napping from i«th virtual page of process 2 to 
the physical page Is not valid anymore. ) 

1} We call vacjflushO from pageoutO of vmjage.c 
• to flush the ttj* part of pushutl. 

{ Xn pageout()7 the mapping from pushutl to the physical 
u page of rp becomes Invalid after the vtod(> call. ) 

n) We call vac flush () from pageoutO of vn^page.c to 
flush the cluster of pages to be paged out. 
( SwapO naps the physical pages of these pages to virtual 
addresses of proct2] before it calls physstratO. Thus, 
the mappings from the outgoing virtual pages to physical 
pages are to be replaced by those of proe [2] virtual pages 
to these physical pages. Therefore, we flush these pages 
In pageoutO before swapO is called. } 

n) We call vac pagef lush (} from kmcopyO of vm^pt.e. 
{ kmcopyO Is called from ptexpandO to "copy" pte'e 
from old pte'a to new pte's. Xt "copies" by napinO 
new pte's to the physical pages of old pte^s. We flush 
old pte's before new pte'^ are napped*in. } 

o) IQs call vac^agef lush 0 from distpteO of vm^.o. 
{ distpteO is called when the pte entries of a shared 
text pte is changed. For example/ pageoutO changes Its 
valid bit to invalid. Since other processes sharing this 
text page nay have this text page in the cache, we flush 
out this page for all sharing processes. ) 

p) We call vac flush 0 from vrelptO of vmjpt.c to flush 
the pte's of the outgoing process. 

( Xn vrelptO, the pages that contains pte's are released 
but napoutO Is not called. ) 
q) We call vac^agef lush () from wlokjunlock of 
sunwindowde v/winlock • e . 



{ In ifloX iinlock()# mpping from tflDck-*>lokjti8er 
to thm physioal v page et the current proeesa beoonee 
invalid if «lock»> lok veer is nonzero. } 
r) We call vac^agef lush (T from wlokjAoneO of 
•unwindewdeT/wix^ock. o. 

< Xn nlok done Of the mapping from wloek*>lokjaaer 
to the phyaieal v page beoemea invalid. ) 
1€) When protection bita are changed and the affeeted portion 
of the cache ahould be flushed. Such places ares 

a) in chgprotO of vm machdep.Cr we change the protection 
of text pages. We"call vac^ageflushO there to avoid 
having any ontry in the cache with different protection 
with the 

b) in aettprocO of vm mabhdep.c ve change the protection 
bita of text pages."* We call vac^flushO to flush 

the text part of the process. (settprotO ia called 
from vm text.c*) 

c) in vac disable kpageO of vm^maehdep.e we call 
vaejpageflushd to flush all cache lines of this page 
before making the page non^caehed. 

V. Why don't we flush the cache here? 

- — The^'foTlowing ITb. list oTplaces where the mapping from 
virtual addresses to physical addresses are changed but the cache 
is not flushed. We describe the reasons why cache flushings 

are not JJ^JJ'Jgl^,, ^ ^ machdep.c, the virtual to physical 

napping of proc p Ts changed to that of proo q. But, q 
gets whatever in the cache previous belong to pi ao no 
need to flush cache for p. ^ ^ ^ m 

1 ctxpassO is called by vpassptO to pass the context of p 
to q. vpassptO is called by vpassvroO which is called before 
and after vforkO . vpassvmO passes the vm resources and 
the HMD context of p to q. When vpassvmO returns , the 
virtual to physical mapping for the context is not changed. 
Since the context is also passed, the affected mappings in 
the cache are still correct, except that now they belong to 
proc q instead of proc p. Therefore, there is no need to 
flush the cache either in ctxpassO or in vpassvmO. ) 

2) m vpassptO, the virtual-to*physical mappings of processes 
"up" and "uq" are not changed when vpassptO returns. 

(Or more precisely, the mappings are changeh back to 
the aame as the mappings when vpassptO is entered). 

3) In swapO of vm^swp.c, i£ "flag" indicates a dirty page 
push, the mapping of addr to physical address is replaced 
by that of the i-th page of proc 12 J. Since dirty pages 
have been flushed in pageoutO, there is no need to flush 
"addr" again in awapO. , 

4) In pmegloadO of vm machdep.c, when •pmxp (ctx pmegiseg]) 
is sero and Ineed, we invalidate pmeg[segl. Since we did 
either a context flush (in ctxfreeO) or a aegment flush 
(in pcnegreleaseO) when we aet ctx pmeglaegl to aero, 
there is no need to do a aegment flush here. 

{ There are only two places where we aet (struct context •)-> 
. ctxj««9l»«9l *o z^TO. One is in pmegrelease () where we 
vac seg£lu8h(seg) and aetsegmap(seg, SEGIHV). 
The^other place is in ctxfreeO where we call vac.etxf lush () 
but don't setsegmapCsegr SEGIKV) . 

Bence (struct context *)->ctxjmeg[segl is aero but MMU 
segmap is not SEGIKV in this case. The reason that 
when *pmxp — 0 and fneed in pmegloadO needs a 
actsegmap(seg, BEGINV) ia to make MKD segmap to be SEGIKV. 
Since we have done a vac ctxflushO in ctxfreeO, thia 
aegment ahould not have any left-over in the cache. ) 

5) In ctxallocO of vm machdep.c« aetsegmapO ia called 
to invalidate all mappinas from the aeoment map. Since 



etxfz««() la called •azlier to flttth tha ^ntiM 
contaxt# no lines associated with these segments 
axe in the cache. TherefozOf segment flushes are not 
needed • 

€) Xn ptssyneO ©£ ^ ■i»ehd.p.c, "pt«»ynoO calls pin»gunlo«d() 
which or'» thm mod bita to pt«'s and sM*t the aed »>^tj of 
th« pneg. When we check if another page in thia pneg is dirty 
we check its pte' which xenenbers the nod bit was en. 
We don't need to flush the segment because pnegunload turns 
©If the »od bits In this pneg. ^ ^ ^ 

7) unloadpgmap 0 of aap.s saves the referenced and nodified 
bite from MHO proe to soft pte and dears these bits in the 
pme. Since when we do pageout ©r swapout, it is the soft 
pte that we check to decide if a page is dirty, there is no 
need to flush the cache when the referenced and a»dified 
bits of a pme is changed. 

8) Xn pmegunloadO of vm naehdep.e, we call setsegmap (CSEC, 
pro-proeg), unloadpgmap( v, pte, num), ""d •etsegmapCCSEG, 
SEGINV). In unloadpgmapO, segment nap of CSEG is used to 
access the pme's in this segment. Virtual address ©f 
segment CSEG is not accessed, thus segment CSEG doesn't 
have anything in the cache. Therefore, there is no need 
to call vac_seg£luBh(CSEG) before we invalidate this 

9) Xn^pouto of vm machdep.o, when we invalidate a 

by calling 8et8eg5lap((ujlnt)ptd8(btop(vaddr) ), (u_char)SE6IHV) 
we have done pageflushes on all previously used pages ^ this 
segment. Therefore, there is no need to do a segment flush. 
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CLAIMS 

.1. In a vorJcetation utilizing a virtual addresB write back 
cache including a central procesBor having an address bus and a 
data bus, a cache data array, having a plurality of cache blocks, 
a cache tag array having an array clement for each of said cache 
blocks, each of said array elements having a Valid bit, a Modified 
bit and a Supervisor Protect bit, a write back buffer, a memory 
management trnit, a main memory, a cache hit detector, a context 
identification register, flush control logic and workstation 
control logic, the Improvement wherein said cache hit detector is 
modified to detect cache hits In a shared operating system across 
multiple active user contexts, and wherein said workstation further 
comprises! 

a) means for reassigning virtual addresses across multiple 
user contexts; 

b) means for completing a cache block flush operation before 
control is returned to the central processor upon the issuance of a 
flush command, and in each said flush operation, flushing all cache 
blocks having their associated cache tag array element Valid bit 
set, prior to reassignment of the virtual addresses. 

2. The improvement defined by Claim 1 wherein said modified 
cache hit detector comprises: 

a) means for detecting cache blocks having their corresponding 
cache tag array' element Valid bit set; 



b) rlrBt &e&ns for detexmlning whether for the cache block 
being eddresBed by the central processor, said cache block address 
having a plurality of access virtual address bits, said access 
virtual address bits match virtual address field bits in a 
corresponding cache tag array eleaenti 

c) second aeans for determining whether i) for the cache block 
being addressed by the central processor, said said cache block 
address having a plurality of access context bits, said access 
context bits match context bits in the corresponding cache tag 
array element; and ii) the Supervisor Protect bit is set in the 
corresponding cache tag array element. 

3. The improvement defined by Claim ^ wherein said 
reassigning meems comprises s 

a set of flush commands disposed within the shared operating 
system, said flush commands being a context match flush command, a 
page match flush command, and a segment match flush command. 

4. The improvement defined by Claim 1 wherein said flush 
operation completing means comprises s 

a) means for decoding said flush command, said flush conunand 
being one of a context match flush command, page match flush 
command and segment match flush command; 

b) flush address register means for storing an address 
included in said decoded flush command; 



c) Incrementing means for incrementing predetermined address 
bits for combining vith the address bits in said flush address 
register means; 

d) flush match means coupled to said decoding means for 
generating a flush match logic signal, 

vhereby the issuance of & flush command causes all cache 
blocXs having their associated Valid bit set to be flushed prior to 
reassigxu&ent of the virtual addresses, 

5. The improvement defined by Claim 2 wherein said detecting 
means comprises a first AKD gate having a first input coupled to 
the Valid bit of the array element in the cache tag array 
corresponding to the cache block being addressed by the central 
processor. 

The improvement defined by Claim ^ wherein said first 
determining means comprises a first comparator coupled to said 
address bus and said cache tag array, the output of said first 
comparator coupled to a second input of said first AND gate. 

7. The improvement defined by Claim ^ wherein said second 
determining means comprises a second comparator coupled to said 
context identification register And said cache tag array, the 
output of said second comparator coupled to a first input of an XOR 
gate, a second input of said XOR gate coupled to the Supervisor 
Protect bit in the cache tag array element corresponding to the 
cache block addressed by the central processor* 



fl. The Improveaent defined by Claim 7 wherein said modified 
cache hit detector further coaprises: 

a) a second AMD gate having one input coupled to the output of 
said XOR gate, a eecond input coupled to the output of said first 
AMD gate and a third input coupled to the output of a third 
coaparator whose inputs are coupled to said address bus and the 
array element of said cache tag array addressed by said central 
processor} 

b) a fourth comparator whose inputs are coupled to said 
address bus and the array element of said cache tag array addressed 
by said central processor, the output of said fourth comparator 
being a third input of said first AMD gate. 

9 . The improvement defined by Claim wherein said 
decoding means comprises an AMD gate coupled to said central 
processor and first, second and third flip-flops having their clock 
inputs coupled to the output of said AND gate and their D-inputs 
coupled to said data bus. 

iq. The inprovement defined by Claim 9 wherein said 
flush address register means comprises a register which loads 
predetermined bits from the address bus when the output of said AMD 
gate is set. 

n. The improvement defined by Claim 9 wherein said 
flush match means comprises first, second and third AND gates, each 
having one input coupled to the Q outputs of said first, second and 



thlrd tllp-flopB respBotlvely and a second Input coupled to taaane 
tox generating a sagnent match signal, a page match signal and a 
context match signal, an OH gate having first, second and third 
Inputs coupled respectively to the outputs of said first, sacond 
and third AKD gates, vhereby the output of said OR gate la set when 
ona of said segnent, page and context match signals are set and a 
corresponding segment, page and segment command has been decoded. 

12. A uorkstation substantially as herein described ulth reference to 
and as illustrated in the accompanying drauings. 
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